[4.2-dev] fix(frontend): preserve logical result cardinality - #26868

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #25992

Follow-up to #26843 (the 4.2-dev backport of #26836).

What this PR does / why we need it:

After #26843 accepts a physical length-1 const vector as a broadcast input, a
prepared grouped query can correctly produce a projection batch whose logical
row count is greater than its first vector's physical length:

SELECT ? AS projection_value, SUM(value_col) AS total
FROM metric_rows GROUP BY bucket ORDER BY total;

The frontend still derived result cardinality from bat.Vecs[0].Length().
Consequently, it emitted only one MySQL result row for a three-row batch and
also undercounted sentRows. Saved query results had a second inconsistency:
their metadata reported three rows, but object storage and result_scan
preserved only the first physical row.

This change uses batch.RowCount(), the logical cardinality propagated by the
projection operator, for protocol output and row accounting. At the query-result
persistence boundary, it validates vector shapes and creates an owned writer
view only when compact const vectors need their logical lengths normalized.
Aligned vectors are borrowed, mismatched const/const-null vectors remain
physically scalar, and the executor-owned input batch is never mutated.

Regression coverage includes flat, const, broadcast const, const-null, malformed
and zero-row batches; allocation/write failure cleanup; real object writer plus
result_scan; SQL-level prepared statement reuse; and the original GROUP BY ?
path.

Validation on the exact 4.2-dev base 9301a23cc8:

• The direct-output BVT on the unfixed base: 19/21 statements pass; both
  parameter-first executions incorrectly return one row.
• On the direct-output-only candidate, EXECUTE returns 3 rows but the immediate
  result_scan(last_query_id()) returns 1 row.
• Focused frontend regressions, -count=10: pass.
• Full pkg/frontend test suite: pass.
• go build -mod=readonly ./pkg/frontend: pass.
• go vet -mod=readonly ./pkg/frontend: pass.
• make build: pass.
• Isolated single-node fixed candidate BVT, including saved scans for first,
  NULL-reuse, and non-first parameters: 26/26 statements pass.
• MySQL binary COM_STMT_PREPARE/EXECUTE probe: parameter-first returns 3 rows,
  NULL statement reuse returns 3 rows, and the [4.2-dev] fix(hashmap): accept broadcast const iterator vectors #26843 grouped-parameter control
  returns 1 row.

Direct output keeps an O(1) cardinality lookup. Saved aligned batches allocate
nothing beyond the existing path. A mismatched const adds an O(column count)
validation and copies only scalar physical storage; no per-row materialization
or global object-writer contract change is introduced.